プラットフォーム間で通信を行なう技術

专利摘要:
種々のネットワークアクセスプラットフォーム（１０６）、（１１２）に配置される機能構成要素（１２０）、（１３０）の間でプラットフォーム間通信を行なう技術について説明する。この技術の１つの方法の態様は、第２のネットワークアクセスプラットフォーム上に配置される第２の機能構成要素（１３０）にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素（１３０）からプラットフォームに基づく機能を要求するように構成される第１の機能構成要素（１２４）を含む第１のネットワークアクセスプラットフォーム（１１２）を提供するステップを含む。第１の機能構成要素（１２０）と第２の機能構成要素（１３０）との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーション（１２２）は、第１のネットワークアクセスプラットフォーム（１１２）にインストールされる。プラットフォーム間通信アプリケーション（１２２）は、第２の機能構成要素（１３０）にアクセスするために提供される第１のミドルウェア機能（１２６）と接続することが可能になる。通信パス（１３４）は、プラットフォーム間通信プリケーション（１２２）及び第１のミドルウェア機能（１２６）を介して第１の機能構成要素（１２０）と第２の機能（構成要素１３０）との間に確立される。
公开号:JP2011512048A
申请号:JP2010534453
申请日:2008-11-17
公开日:2011-04-14
发明作者:セイド−ハミ ヌールバクーシ，；ベルント モ−ラー，；ユルゲン レルツァー，
申请人:テレフオンアクチーボラゲット エル エム エリクソン（パブル）；
IPC主号:H04W88-06

专利说明:

[0001] 本発明は、一般に、ネットワークアクセス技術（ＮＡＴ）に関する。特に、本発明は、第１のネットワークアクセスプラットフォームに配置される機能構成要素が第２のネットワークアクセスプラットフォームに配置される機能構成要素と通信することを可能にする技術に関する。]
背景技術

[0002] 従来、移動電話は、全ての通信タスクを処理する自社開発したオペレーティングシステムを有する音声中心のデバイスであった。これらのデバイスのアプリケーションプログラミングインタフェース（ＡＰＩ）は、第三者の開発者が利用できなかった。その結果、エンドユーザは、アプリケーションに関してデバイスの製造業者に依存していた。]
[0003] 今日、移動通信業界では、移動デバイスに対するオープンアプリケーション環境の重要性及び利点に対する認識が次第に高まってきている。基本的には、オープンアプリケーション環境により、デバイスの製造中に又はデバイスを動作させているユーザにより後で移動デバイスに第三者アプリケーションをインストールできる。そのような第三者アプリケーションは、ゲーム、ソフトウェア、アップグレード等を含む。]
[0004] A. Ghosh他の「Open application environments in mobile devices: Focus on JME and Ericsson Mobile Platforms」Ericsson Review No. 2、Vol. 82、２００５年、８２〜９１ページ（ISSN: 0014-0171）において、移動デバイスに対する例示的なオープンアプリケーション環境が説明される。オープンアプリケーション環境は、汎用パケット無線サービス（ＧＰＲＳ）、ＧＳＭの拡張向け高速データ（ＥＤＧＥ）又は広帯域符号分割多元接続（ＷＣＤＭＡ）等のいわゆる無線アクセス技術（ＲＡＴ）である無線ＮＡＴをサポートするデジタルベースバンドプロセッサを有するモバイルプラットフォームに基づく。モバイルプラットフォームは、全ての必要な集積回路、並びに無線ネットワークアクセスサービス及び通信サービス（例えば、音声、データ又はマルチメディアアプリケーション向け）を提供するのに必要なソフトウェアに加えて、モバイルプラットフォームに常駐するアプリケーションがそれらのサービスを利用できるようにするインタフェースを含む環境である。]
[0005] A. Ghosh他により説明されるオープンアプリケーション環境において、専用ミドルウェアサービスは、データストリームの分解能及び符号化等のプラットフォーム内の機能性のアプリケーションを用いた制御を可能にするために提供される。これらのミドルウェアサービスは、明確に規定された種々のカテゴリに構造化されるＡＰＩ（いわゆるオープンプラットフォームＡＰＩ、すなわちＯＰＡ）を含む。このＯＰＡの構造により、アプリケーションプログラマがプラットフォーム別の機能性の位置を特定し且つアドレス指定することは容易になる。]
[0006] 従来、モバイルプラットフォームは、自社開発のオペレーティングシステム（ＯＳ）を含むことが多かった。現在では、オープンアプリケーション環境の出現により、第三者アプリケーションプロセッサを含むアプリケーションプラットフォームは、Symbian等のオープンＯＳを実行させることが望まれる場合に移動デバイスに追加されるだろう。アプリケーションプラットフォームは、移動デバイスにおいてモバイルプラットフォームと同一の場所に配置され、例えばマルチメディアアプリケーションを含む全てのアプリケーションに対処する。一方では、モバイルプラットフォームは、減少された機能性の集合（無線ネットワークアクセス等の全ての移動通信タスクを含む）を管理し、主にネットワークアクセスプラットフォームとして動作する。アプリケーションプラットフォームとモバイルプラットフォームとの間において、インタフェース機構は、アプリケーションがモバイルプラットフォーム上に直接常駐するかのように、アプリケーションプラットフォーム上のアプリケーションにモバイルプラットフォーム内の機能性に対するアクセス権（ＯＰＡを介する）を提供する。]
[0007] 場合によっては、２つ以上のＮＡＴを移動デバイスに備える必要があるか又は備えることが望ましい。この点に関して、国際公開第ＷＯ−Ａ−００／２２８５７号は、いわゆるネットワークアクセスモジュール（ローカルエリアネットワーク（ＬＡＮ）モジュール及び汎ヨーロッパデジタル移動通信システム（ＧＳＭ）モジュール等）の形態の種々のネットワークアクセスプラットフォームがＵＳＢ（Universal Serial Bus）規格に従う通信バスを介して相互接続されるモジュラ手法を教示する。閉回路テレビ（ＣＣＴＶ）モジュール等の通信バスに接続される他のモジュールは、一方ではＬＡＮモジュールを介し又は他方ではＧＳＭモジュールを介して信号を選択的に送信してもよい。]
[0008] ネットワークアクセスプラットフォームに互いに直接通信させることは有利であることが分かっている。例えばネットワークアクセスプラットフォーム間のハンドオーバ信号伝送において低レベル制御機構を実現するために、そのような直接通信は望ましい。更に、特定の例においては、そのようなプラットフォーム間通信の概念をオープンアプリケーション環境に互換性のあるものにするのが望ましい。]
[0009] 従って、２つ以上のネットワークアクセスプラットフォーム間の低レベル通信を可能にする効率的な技術が必要とされる。]
[0010] 第１の態様によると、この必要性は、種々のネットワークアクセスプラットフォームに配置される機能構成要素間の通信を可能にする方法により満足される。方法は、第２のネットワークアクセスプラットフォームに配置される第２の機能構成要素にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素からプラットフォームに基づく機能を要求するように構成される第１の機能構成要素を含む第１のネットワークアクセスプラットフォームを提供するステップと、第１の機能構成要素と第２の機能構成要素との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーションを第１のネットワークアクセスプラットフォームにインストールするステップと、プラットフォーム間通信アプリケーションが第２の機能構成要素にアクセスするために提供される第１のミドルウェア機能と接続することを可能にするステップと、プラットフォーム間通信プリケーション及び第１のミドルウェア機能を介して第１の機能構成要素と第２の機能構成要素との間に通信パスを確立するステップとを含む。]
[0011] 第１の変形例によると、第１のミドルウェア機能は、第１のネットワークアクセスプラットフォームにインストールされる。第２の変形例によると、第１のミドルウェア機能は、第２のネットワークアクセスプラットフォームを介してアクセス可能である。このために、第１のミドルウェア機能は、第２のネットワークアクセスプラットフォームにインストールされてもよい（例えば、第２のネットワークアクセスプラットフォーム内に物理的にインストールされるか又は第２のネットワークアクセスプラットフォーム上に論理的にインストールされる）。ミドルウェア機能が第２のネットワークアクセスプラットフォームにインストールされる場合、第１のミドルウェア機能に向けられる任意の信号伝送は、第２のネットワークアクセスプラットフォームを介してルーティングされる。]
[0012] 第１のミドルウェア機能が第２のネットワークアクセスプラットフォームを介してアクセス可能である場合、あるいはプラットフォーム間通信を要求する他の例において、１つ以上のプラットフォーム間通信インタフェースが提供されてもよい。この点に関して、第１のインタフェースは、第１のネットワークアクセスプラットフォームに提供されてもよく、プラットフォーム間通信アプリケーションが第１のミドルウェア機能と接続することを可能にするステップは、第１のネットワークアクセスプラットフォームの第１のインタフェースを第２のネットワークアクセスプラットフォームの第２のインタフェースに結合することを含んでもよい。]
[0013] 第１のネットワークアクセスプラットフォーム及び第２のネットワークアクセスプラットフォームの双方は、１つ以上の制御及び／又はデータインタフェースを備えてもよい。一実現例において、各プラットフォームは、少なくとも１つの制御インタフェース及び少なくとも１つのデータインタフェースを含み、１つのプラットフォームの制御インタフェース及びデータインタフェースは、他のプラットフォームの制御インタフェース及びデータインタフェースにそれぞれ結合される。]
[0014] 制御インタフェースは、サポートされるデータ転送速度に関してデータインタフェースと異なってもよい。一般に、ＵＳＢ規格に従うインタフェース等のデータインタフェースは、例えば汎用非同期送受信機（ＵＡＲＴ）規格又は汎用入出力（ＧＰＩＯ）規格に従う制御インタフェースより速いデータ転送速度をサポートする。]
[0015] 方法は、第１のネットワークアクセスプラットフォームにより第２のネットワークアクセスプラットフォームから第１のミドルウェア機能をインポートするステップを更に含んでもよい。インポートの１つの変形例によると、第１のミドルウェア機能のプログラムコードは、１つ以上のプラットフォーム間通信インタフェースを介して第２のネットワークアクセスプラットフォームから第１のネットワークアクセスプラットフォームに転送される。更なる変形例によると、インポートステップは、実際には第２のネットワークアクセスプラットフォームにインストールされた状態のままである第１のミドルウェア機能を第１のネットワークアクセスプラットフォームに対して可視化することを含む。]
[0016] 第１の機能構成要素と第２の機能構成要素との間のプラットフォーム間通信パスは、第１のネットワークアクセスプラットフォームと第２のネットワークアクセスプラットフォームとの間で転送された信号をカプセル化及び非カプセル化するように構成されるカプセル化機構を更に含んでもよい。カプセル化及び非カプセル化処理は、発呼側及び／又は着呼側機能構成要素の識別子、並びに着呼側機能構成要素により提供される機能の入力又は出力パラメータ等の種々の信号コンテンツに関連してもよい。カプセル化処理中、信号コンテンツは、１つ以上の物理データユニット（ＰＤＵ）にパックされてもよく、非カプセル化処理は、ＰＤＵの対応するアンパックを含んでもよい。一実現例において、カプセル化及び非カプセル化処理は、発呼側及び着呼側機能構成要素に対して透過的に実行される。]
[0017] カプセル化機構は、第１のネットワークアクセスプラットフォーム及び第２のネットワークアクセスプラットフォームにわたってもよく、プラットフォーム間通信機構を効果的に構成してもよい。特にプラットフォーム間通信アプリケーションが第１のネットワークアクセスプラットフォームにインストールされ且つ第１のミドルウェア機能が第２のネットワークアクセスプラットフォームを介してアクセス可能である場合、カプセル化機構は、プラットフォーム間通信プリケーションと第１のミドルウェア機能との間で通信パスに論理的に挿入されてもよい。カプセル化機構は、第１のネットワークアクセスプラットフォームにインストールされたプラットフォーム間通信アプリケーションに対して第１のミドルウェア機能を可視化する（上述したインポートの第２の変形例に従う）伝達手段であってもよい。]
[0018] 場合によっては、発呼側機能構成要素は、着呼側機能構成要素が別のネットワークアクセスプラットフォームに配置されることを認識する必要がない。そのような場合、１つ以上の仮想機能構成要素を通信パスに挿入することは有利であり、各仮想機能構成要素は発呼側機能構成要素のローカルネットワークアクセスプラットフォーム上に着呼側機能構成要素が存在することを発呼側機能構成要素に対してシミュレートしてもよい。第２のネットワークアクセスプラットフォームに配置される仮想機能構成要素は、第２のネットワークアクセスプラットフォーム上に第１の機能構成要素（実際には第１のネットワークアクセスプラットフォームに配置される）が存在することを第２の機能構成要素（第２のネットワークアクセスプラットフォームに配置される）に対してシミュレートしてもよく、またその逆も成り立つ。]
[0019] １つ以上の仮想機能構成要素は、通信部分において起こる信号伝送に関してプラットフォーム変換タスクを実行するために提供されてもよい。各仮想機能構成要素は、例えば発呼側機能構成要素から受信した要求をプラットフォーム間通信アプリケーションにより読み取られる要求メッセージに変換してもよく、またその逆も成り立つ。この点に関して、仮想機能構成要素は、発呼側機能構成要素とプラットフォーム間通信アプリケーションとの間の変換機構として解釈され、着呼側機能構成要素に対するある種のプロキシとして動作してもよい。]
[0020] 場合によっては、任意の機能構成要素により生成されるか又は任意の仮想機能構成要素を介してルーティングされる（且つ可能性として任意の仮想機能構成要素により変換される）信号伝送イベントをプラットフォーム間通信アプリケーションに通知するのが望ましい。このために、プラットフォーム間通信アプリケーションは、１つ以上の機能構成要素及び仮想機能構成要素に対して、プラットフォーム内の任意の（又は特定の）信号伝送イベントがプラットフォーム間通信アプリケーションに信号伝送されることを通知してもよい。そのような通知は、プラットフォーム間通信アプリケーションにより１つ以上の機能構成要素及び／又は仮想機能構成要素の信号伝送イベントを購読するものとして考えられる。]
[0021] プラットフォーム間通信アプリケーションは、通信パスにおいて行なわれる信号伝送に対して変換タスクを実行してもよい。そのような変換タスクは、発呼側機能構成要素又は仮想機能構成要素からの信号伝送イベント（着呼側機能構成要素により読み取り可能でない可能性がある）を着呼側機能構成要素により読み取り可能な形式に変換することを含んでもよい。]
[0022] 第１の機能構成要素と第２の機能構成要素との間の通信パスは、種々の信号伝送の目的で使用されてもよい。第１の変形例によると、信号伝送は、種々のネットワークアクセスプラットフォームに展開されるＮＡＴ間の内部ハンドオーバに関係する。プラットフォーム間の信号伝送は、一般に汎用集積回路カード（ＵＩＣＣ）及び特に購読者識別モジュール（ＳＩＭ）カード等のメモリカード又はスマートカードにアクセスする際に行なわれてもよい。２つのプラットフォームがモデムタスクを実行するように構成される場合、種々の機能構成要素間の確立された通信パスを介して転送される信号は、Hayesコマンドセット（ＡＴコマンドとも呼ばれる）に属するコマンド等の１つ以上のモデムコマンドを含んでもよい。当然、通信パスは、任意の他のシステム制御信号を転送するために使用されてもよい。]
[0023] 一例において、第１のネットワークアクセスプラットフォームに配置される第１の機能構成要素へのアクセス権を提供するように構成される第２のミドルウェア機能が提供される。第２のミドルウェア機能は、プラットフォーム間通信アプリケーションと第１の機能構成要素との間で通信パスにおいて論理的に構成されてもよい。第２のミドルウェア機能は、第１のネットワークアクセスプラットフォームを介してアクセス可能であってもよい。必要に応じて、第２のミドルウェア機能は、第２のネットワークアクセスプラットフォームにインストールされてもよい。]
[0024] 第１のミドルウェア機能及び第２のミドルウェア機能のうち少なくとも一方はＡＰＩを含んでもよい。例えば、第１のミドルウェア機能は第２の機能構成要素と関連してＡＰＩを提供してもよく、第２のミドルウェア機能は第１の機能構成要素と関連してＡＰＩを提供してもよい。特にオープンアプリケーション環境において、各ＡＰＩはＯＰＡとして構成されてもよい。そのような場合、第１の機能構成要素及び第２の機能構成要素のうち少なくとも一方は、オープンアプリケーション環境のアプリケーションに更にアクセス可能であってもよい。これらのアプリケーションは、１つ又は全てのネットワークアクセスプラットフォーム、あるいは専用アプリケーションプロセッサを含む別個のアプリケーションンプラットフォームに常駐してもよい。]
[0025] 一般に、ネットワークアクセスプラットフォームによりサポートされるＮＡＴは、有線ＮＡＴであってもよく又は無線ＮＡＴであってもよい。好適な変形例において、第１のネットワークアクセスプラットフォームは、少なくとも１つの第１の無線アクセス技術（ＲＡＴ）をサポートする第１のベースバンドプロセッサを含み、第２のネットワークアクセスプラットフォームは、第２のＲＡＴをサポートする第２のベースバンドプロセッサを含む。第２のＲＡＴは、少なくとも１つの第１のＲＡＴと異なってもよい。第１のネットワークアクセスプラットフォーム及び第２のネットワークアクセスプラットフォームは、単一のデバイス内で同一の場所に配置されてもよい。そのようなデバイスは、少なくとも１つのネットワークアクセスプラットフォームに結合される１つ以上のアプリケーションプロセッサ（例えば、１つ以上のアプリケーションプラットフォームに配置される）を更に含んでもよい。]
[0026] 別の態様によると、種々のネットワークアクセスプラットフォームに配置される機能構成要素間の通信を可能にする更なる方法が提供される。方法は、第２のネットワークアクセスプラットフォームに配置される第２の機能構成要素にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素からプラットフォームに基づく機能を要求するように構成される第１の機能構成要素を含む第１のネットワークアクセスプラットフォームを提供するステップと、第１の機能構成要素へのアクセスを可能にするミドルウェア機能（例えば、プラットフォーム間通信アプリケーション）を第１のネットワークアクセスプラットフォームにインストールするステップと、ミドルウェア機能及びプラットフォーム間通信アプリケーションを介して第１の機能構成要素と第２の機能構成要素との間に通信パスを確立するステップとを含む。]
[0027] 本明細書で提示される技術は、ソフトウェアの形態で、ハードウェアの形態で又は組合せソフトウェア／ハードウェア手法を使用して実現されてもよい。ソフトウェアの側面に関して、コンピュータプログラム製品が１つ以上の演算装置上で実行される時に本明細書で提示されるステップを実行するためのプログラムコード部分を含むコンピュータプログラム製品が提供される。コンピュータプログラム製品は、メモリチップ、ＣＤ−ＲＯＭ及びハードディスク等のコンピュータ可読記録媒体に格納されてもよい。]
[0028] ハードウェアの側面に関して、種々のネットワークアクセスプラットフォームに配置される機能構成要素間の通信を可能にするように構成されるプラットフォームシステムが提供される。システムは、第２のネットワークアクセスプラットフォームに配置される第２の機能構成要素にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素からプラットフォームに基づく機能を要求するように構成される第１の機能構成要素を含む第１のネットワークアクセスプラットフォームと、第１のネットワークアクセスプラットフォームにインストールされ且つ第１の機能構成要素と第２の機能構成要素との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーションと、プラットフォーム間通信アプリケーションが第２の機能構成要素にアクセスするために提供されるミドルウェア機能と接続することを可能にするように構成されるインタフェースと、プラットフォーム間通信プリケーション及びミドルウェア機能を介して第１の機能構成要素と第２の機能構成要素との間に通信パスを確立するように構成される制御器とを含む。]
[0029] プラットフォームシステムは、ユニバーサル移動通信システム（ＵＭＴＳ）規格に従って動作するように構成されてもよい。更にインタフェースは、ＵＳＢとして及び／又は汎用非同期送受信機（ＵＡＲＴ）インタフェースとして構成されてもよい。]
[0030] ハードウェアの別の側面によると、種々のネットワークアクセスプラットフォームに配置される機能構成要素間の通信を可能にするように構成されるプラットフォームシステムが提供される。システムは、第２のネットワークアクセスプラットフォームに配置される第２の機能構成要素にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素からプラットフォームに基づく機能を要求するように構成される第１の機能構成要素を含む第１のネットワークアクセスプラットフォームと、第１のネットワークアクセスプラットフォームにインストールされ且つ第１の機能構成要素へのアクセスを可能にするように構成されるミドルウェア機能（例えば、プラットフォーム間通信アプリケーション）と、ミドルウェア機能及びプラットフォーム間通信アプリケーションを介して第１の機能構成要素と第２の機能構成要素との間に通信パスを確立するように構成される制御器とを含む。プラットフォームシステムは、ＬＴＥ（Long Term Evolution）規格に従って動作するように構成されてもよい。]
[0031] 上述の２つのプラットフォームシステムは、共通の制御器を有するか又は別個の制御エンティティを有する単一のデバイスに含まれてもよい。デバイスは、ネットワークカード、携帯端末及び移動電話のうちの少なくとも１つとして構成されてもよい。機能構成要素は、レイヤ１（Ｌ１）ＲＡＴ測定、ＳＩＭアクセス、ハンドオーバ信号伝送（例えば、内部のＮＡＴ間）、モデムコマンド信号伝送（例えば、１つのプラットフォームがアプリケーションに対するモデムとして動作するか又は機能構成要素が他のプラットフォームに常駐する）及び一般的なプラットフォーム制御機能性を提供するハードウェア又はソフトウェアモジュールとして実現されてもよい。]
図面の簡単な説明

[0032] 本明細書で提示する技術の更なる態様及び利点は、以下の好適な実施形態及び図面の説明から明らかとなるだろう。
図１は、２つのプラットフォームシステム実施形態を組み込む第１のデバイス実施形態を示す概略図である。
図２は、２つのプラットフォームシステム実施形態を組み込む第２のデバイス実施形態を示す概略図である。
図３は、第１の方法実施形態を示すフローチャートである。
図４は、第２の方法実施形態を示すフローチャートである。
、
、
図５ａ〜図５ｃは、単一のプラットフォームシステムの解決策から２つのデュアルプラットフォームシステム実施形態への遷移を示す概略図である。
図６は、２つのプラットフォームシステム実施形態にわたる例示的なカプセル化機構を示す概略図である。
図７は、論理プラットフォーム間インタフェースを示す概略図である。
図８は、インタフェースの第１の変形例に従って結合される２つのプラットフォームシステム実施形態を示す概略図である。
図９は、インタフェースの第２の変形例に従って結合される２つのプラットフォームシステム実施形態を示す概略図である。
図１０は、インタフェースの第３の変形例に従って結合される２つのプラットフォームシステム実施形態を示す概略図である。
図１１は、種々のプラットフォームシステムの実施形態に配置される２つの機能構成要素を含む第１の信号伝送実施形態を示す概略図である。
図１２は、種々のプラットフォームシステムの実施形態に配置される２つの機能構成要素を含む第２の信号伝送実施形態を示す概略図である。
図１３は、種々のプラットフォームシステムの実施形態に配置される２つの機能構成要素を含む第３の信号伝送実施形態を示す概略図である。
図１４は、種々のプラットフォームシステムの実施形態に配置される２つの機能構成要素を含む第４の信号伝送実施形態を示す概略図である。] 図１ 図１０ 図１１ 図１２ 図１３ 図１４ 図２ 図３ 図４ 図５ａ
実施例

[0033] 以下の好適な実施形態の説明において、限定せず且つ説明する目的で、本発明を完全に理解するために詳細な説明が示される（特定のインタフェース、ネットワークアクセス技術及び一連のステップ）。本発明がそれらの特定の詳細からそれた他の実施形態で実現されてもよいことは、当業者には理解されるだろう。例えば、実施形態がＵＭＴＳ及びＬＴＥ規格等の第３世代及び第４世代の移動通信規格と関連して主に説明されるが、本発明は、例えばＧＳＭ規格に従う第２世代の移動通信技術と関連して実現可能であることが明らかとなる。]
[0034] 更に、本明細書において以下に説明されるサービス、機能及びステップは、プログラムされたマイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）又は汎用コンピュータと共に機能するソフトウェアを使用して実現されてもよいことが当業者には理解されるだろう。以下の実施形態が主に方法及びデバイスに関して説明されるが、本発明は、コンピュータプログラム製品、並びにコンピュータプロセッサ及びプロセッサに結合されるメモリを含むシステムにおいて実施されてもよいことが更に理解されるだろう。ここで、メモリは、本明細書で開示されるサービス、機能及びステップを実行してもよい１つ以上のプログラムにより符号化される。]
[0035] 以下において、インタフェース（例えば、ＡＰＩ及び特にＯＰＡ等）の形態のミドルウェア機能を参照する。一般にそのようなミドルウェア機能は、プラットフォーム内部インタフェースの抽象化を行なう。これは、ミドルウェアインタフェースより上位の任意の構成要素又はインタフェースがミドルウェアインタフェースより下位の構成要素及びインタフェースの変更により影響を受けるべきではない（すなわち、それらの構成要素及びインタフェースの変更に依存するべきでない）ことを意味する。いくつかのミドルウェアインタフェースは、いくつかのメッセージ又は通信に対して透過的であってもよい。]
[0036] 例えばＯＰＡは、任意の開発者がプラットフォームの実現の詳細を考慮する必要がないようにオブジェクトパラダイムに構築されてもよい。従って、ＯＰＡは、アプリケーションソフトウェアに対する特定のハードウェア及びオペレーティングシステムの依存性を低減する。最初に説明したように、ＯＰＡサービスは、機能構造及びＯＰＡサービスの分割を取得するためにカテゴリ及びサブカテゴリに編成されてもよい。各サブカテゴリは、複数の構成要素を含んでもよく、それらの構成要素は、ＯＰＡサービスを使用するために１つ以上のインタフェースを提供してもよい。一般に構成要素は、このサブカテゴリの機能性に対するオブジェクトモデルを規定し、構成要素の各インタフェースは１つ以上のメソッドから構成されてもよい。]
[0037] ＯＰＡパラダイムは、同期サービス及び非同期サービスを含んでもよい。同期サービスは、サービスが完了し且つ結果が返されるまで要求クライアントを阻止するが、非同期サービスは、結果（又はイベント）が入手可能になるまで要求クライアントが任意の実行中の処理を継続してもよいため非ブロッキングサービスである。非同期サービスは、非同期要求サービス及び非同期購読サービスに分割されてもよい。本明細書で説明されるＯＰＡは、非同期結果／イベントメッセージを処理する２つの異なるモード、すなわちいわゆるフルメッセージモード及びコールバックモードをサポートしてもよい。フルメッセージモードは完全なメッセージループを常に制御しており、その一方で、コールバックモードはメッセージループを隠し且つ上位サポートを提供し、それに従ってメッセージは機能に直接ルーティングされる。]
[0038] 図１は、２つ以上のＮＡＴを介するネットワークアクセスを確立できるデバイス１００の一実施形態を概略的に示す。デバイス１００は、ネットワークカードとして、パーソナルデジタルアシスタント（ＰＤＡ）等の携帯端末として又は移動電話として構成されてもよい。] 図１
[0039] 図１に示すように、デバイス１００は、ネットワークアクセスを提供するように構成されるネットワークアクセスプラットフォームシステム１０２、１０４の２つの実施形態を含む。尚、デバイス１００は１つ以上の更なるＮＡＴをホストし且つ／又は１つ以上のアプリケーションプロセッサをホストする１つ以上の更なるプラットフォームシステム（不図示）を含むことができる。各プラットフォームシステム１０２、１０４は、別個のＡＳＩＣの形態で実現されてもよく、専用プラットフォームプロセッサを含んでもよい。尚、デバイス１００が２つの別個のネットワークアクセスプラットフォームシステム１０２、１０４を含むため、ある特定のハードウェア、例えば電源構成要素及び無線周波数（ＲＦ）構成要素は双方のプラットフォームシステム１０２、１０４により共有されてもよい。] 図１
[0040] 各プラットフォームシステム１０２、１０４は、３つの専用層に論理的に構造化される。特に各プラットフォームシステム１０２、１０４は、ネットワークアクセスプラットフォーム層（以下において、「プラットフォーム」とも呼ばれる）１０６、１１２、ミドルウェア層（以下において、「ミドルウェア」とも呼ばれる）１０８、１１４、並びにアプリケーション層（以下において、「アプリケーション」とも呼ばれる）１１０、１１８を含む。各層１０６、１０８等は、ソフトウェアの形態で、ハードウェアの形態で又はソフトウェア／ハードウェアの組合せとして実現されてもよい１つ以上の構成要素を論理的に含んでもよい。尚、いくつかの例において、層は構成要素を含まなくてもよく、そのような状況において、対応する層が実現される必要は全くない。図１に示す例において、これは、プラットフォームシステム１０２のアプリケーション１１０及びプラットフォームシステム１０４のミドルウェア１１４に当てはまる。] 図１
[0041] 引き続き図１を参照すると、プラットフォームシステム１０４のプラットフォーム１１２は、プラットフォームシステム１０２のネットワークアクセスプラットフォーム１０６に配置されるリモート機能構成要素にプラットフォームに基づく機能を提供し且つ／又はリモート機能構成要素からプラットフォームに基づく機能を要求するように構成される機能構成要素１２０を含むネットワークアクセスプラットフォームとして構成される。プラットフォームシステム１０４は、ネットワークアクセスプラットフォーム１１２に（ここでは「上に」を意味する）論理的にインストールされ且つ機能構成要素１２０とプラットフォームシステム１０２に常駐するリモート機能構成要素との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーション１２２を更に含む。] 図１
[0042] プラットフォーム１１２は、プラットフォーム間通信アプリケーション１２２がリモートミドルウェア機能１２６と接続することを可能にするように構成されるインタフェース１２４を更に含む。図１に示す実施形態において、ミドルウェア機能１２６は、プラットフォームシステム１０２のミドルウェア層１０８に配置される。プラットフォーム間通信アプリケーション１１２がミドルウェア機能１２６と接続することを可能にするために、プラットフォーム間の接続は、インタフェース１２４及びプラットフォームシステム１０２のプラットフォーム１０６に属する対応するインタフェース１２８を介して確立される。] 図１
[0043] ミドルウェア機能１２６は、プラットフォーム１０６上のインタフェース１２８と同一の場所に配置される機能構成要素１３０へのアクセス権を提供するように構成される。一般にミドルウェア機能１２６は、機能構成要素１３０に対してＡＰＩとして及び特にＯＰＡとして構成されてもよい。]
[0044] プラットフォームシステム１０４は、一方ではプラットフォームシステム１０４のプラットフォーム１１２に常駐する機能構成要素１２０と他方ではプラットフォームシステム１０２のプラットフォーム１０６に常駐する機能構成要素１３０との間で信号を転送するために通信パス１３４を確立するように構成される制御器１３２を更に含む。通信パス１３４は、プラットフォーム間通信アプリケーション１２２及びミドルウェア機能１２６にわたる。]
[0045] 図１に示すように、通信パス１３４は、プラットフォームシステム１０２のプラットフォーム層１０６内から開始し、プラットフォームシステム１０４のプラットフォーム層１１２内で終了する。通信パス１３４は、機能構成要素１２０と機能構成要素１３０との間の低レベルプラットフォーム間通信を可能にする。図１の実施形態において、「低レベル」という用語は、互いに通信する機能構成要素１２０、１３０がアプリケーション層１１０、１１６及びミドルウェア層１０８、１１４より下位に配置されることを示す。機能構成要素１２０、１３０の一方又は双方により提供されるプラットフォーム内の機能性は、２つのプラットフォームシステム１０２、１０４において共有されてもよい。] 図１
[0046] 図１に示す実施形態に関して、制御器１３２は、プラットフォームシステム１０４又はプラットフォームシステム１０２に配置されてもよい。制御器１３２は、プラットフォームシステム１０２により提供されるいくつかの制御機能性及びプラットフォームシステム１０４により提供される他の制御機能性を有する分散構成要素であってもよい。更に別の変形例によると、制御器１３２は、少なくとも部分的にプラットフォームシステム１０２及びプラットフォームシステム１０４の双方の外側のデバイス１００の構成要素であってもよい。] 図１
[0047] 図２は、２つのプラットフォームシステム実施形態１０２、１０４を含むデバイス１００の更なる実施形態を示す。図１と同一の図中符号は、同一又は同様の構成要素を示すために使用され、図１及び図２の２つの実施形態の間の相違点のみを以下に更に詳細に説明する。] 図１ 図２
[0048] 図２から明らかとなるように、図２に示す実施形態に対する最も重要な相違点は、プラットフォームシステム１０２のミドルウェア層１０８には配置されなくなったミドルウェア機能１２６に関係する。ミドルウェア機能１２６は、プラットフォームシステム１０４のミドルウェア層１１４に移動されている。ミドルウェア機能１２６は、プラットフォーム間通信アプリケーション１２２とミドルウェア機能１２６との間に論理的に配置されるプラットフォーム内インタフェース（図２には示さない）を介してプラットフォーム間通信アプリケーション１２２と接続される。図１に示す例と同様に、通信パス１３４は、機能構成要素１２０からプラットフォーム間通信アプリケーション１２２及びミドルウェア機能１２６を介してプラットフォームシステム１０２のプラットフォーム１０６に配置される機能構成要素１３０まで及ぶ。] 図１ 図２
[0049] 図示しない更に別のデバイス実施形態によると、プラットフォーム間通信アプリケーション１２２は、プラットフォームシステム１０４のアプリケーション層１１６からプラットフォームシステム１０２のアプリケーション層１１０に移動可能である。そのような一実施形態において、ミドルウェア機能１２６は、プラットフォームシステム１０２のミドルウェア層１０８内に配置される（図１に示すように）。通信パスは、プラットフォームシステム１０４の機能構成要素１２０からプラットフォーム間インタフェース１２４、１２８を介してプラットフォーム間通信アプリケーション１２２まで達し、またそこからミドルウェア機能１２６を介してプラットフォームシステム１０２の機能構成要素１３０まで及ぶ。] 図１
[0050] 次に、種々のネットワークアクセスプラットフォームに配置される機能構成要素間の通信を可能にする２つの方法実施形態について、図３のフローチャート３００及び図４のフローチャート４００を参照して説明する。これらの方法実施形態は、上述のプラットフォームシステム１０２、１０４により又は適切な構成を有する他のプラットフォームシステムにより実現されてもよい。] 図３ 図４
[0051] 図３のフローチャート３００を参照すると、第２のネットワークアクセスプラットフォームに配置される第２の機能構成要素にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素からプラットフォームに基づく機能を要求するように構成される第１の機能構成要素を含む第１のネットワークアクセスプラットフォームを提供することから開始する（ステップ３０２）。] 図３
[0052] 次のステップ３０４において、プラットフォーム間通信アプリケーションは第１のネットワークアクセスプラットフォームにインストールされる。プラットフォーム間通信アプリケーションは、第１のネットワークアクセスプラットフォームの第１の機能構成要素と第２のネットワークアクセスプラットフォームの第２の機能構成要素との間の信号伝送を制御するように構成される。]
[0053] その後のステップ３０６において、プラットフォーム間通信アプリケーションは、第２の機能構成要素にアクセスするために提供されるミドルウェア機能と接続することが可能になる。このために、プラットフォーム内又はプラットフォーム間インタフェースが提供されてもよい。]
[0054] 更なるステップ３０８において、通信パスは、プラットフォーム間通信アプリケーション及びミドルウェア機能を介して第１の機能構成要素と第２の機能構成要素との間に確立される。この通信パスは、２つの機能構成要素間の低レベル通信を可能にする。]
[0055] 図４のフローチャート４００に示す更なる方法実施形態によると、初期ステップ４０２において、第１の機能構成要素を含む第１のネットワークアクセスプラットフォームが提供される。第１の機能構成要素は、第２のネットワークアクセスプラットフォームに配置される第２の機能構成要素にプラットフォームに基づく機能を提供し且つ／又は第２の機能構成要素からプラットフォームに基づく機能を要求するように構成される。] 図４
[0056] 更なるステップ４０４において、ミドルウェア機能は、第１のネットワークアクセスプラットフォームにインストールされる。ミドルウェア機能により、プラットフォーム間通信アプリケーションは第１の機能構成要素にアクセスできる。]
[0057] その後のステップ４０６において、通信パスは、第１のネットワークアクセスプラットフォームの第１の機能構成要素と第２のネットワークアクセスプラットフォームの第２の機能構成要素との間に確立される。通信パスは、ミドルウェア機能及びプラットフォーム間通信アプリケーションまで達する。]
[0058] 以下において、システムプラットフォームの構成及び通信パスを確立する処理（及び確立されたアプリケーションパスを介して転送される信号）について更に詳細に説明する。最初に、スタンドアロン構成を有するプラットフォームシステムから同一デバイスにおいて同一の場所に配置される別のプラットフォームシステムと共にデュアルモード構成で動作可能なプラットフォームシステムへの遷移について図５を参照して説明する。]
[0059] 図５ａは、スタンドアロン構成のプラットフォームシステム２０２を示す。プラットフォームシステム２０２は、単一のネットワークアクセスプラットフォームのみを含む従来のデバイスにおいて使用されてもよい。しかし、プラットフォームシステム２０２は、図５ｂ及び図５ｃを参照して後述されるように１つ以上の追加のプラットフォームシステムと組み合わせてデバイスにおいて使用されてもよい。図５ａに示すプラットフォームシステム２０２は、図１及び図２に示すプラットフォームシステム１０２、１０４のいずれかから導出されてもよい。] 図１ 図２ 図５ａ 図５ｂ 図５ｃ
[0060] 図５ａに示すように、プラットフォームシステム２０２は、最下位層にネットワークアクセスプラットフォーム２０４、ミドルウェア機能２０６を含むミドルウェア層及びアプリケーション２０８を含むアプリケーション層を含む。] 図５ａ
[0061] 図５ａに示す実施形態において、ネットワークアクセスプラットフォーム２０４は、ＬＴＥ規格に従ってＲＡＴをサポートする。ＬＴＥプラットフォーム２０４は、２つの機能構成要素２１０、２１２（「モジュールＸ」及び「モジュールＺ」）を含む。機能構成要素２１０、２１２は、プラットフォームに基づく機能を互いに提供し且つ要求するように構成される。そのようなプラットフォームに基づく機能は、レイヤ１（Ｌ１）測定、ハンドオーバ信号伝送、ＳＩＭアクセス又はプラットフォームレベルにおける一般的なシステム制御機能性等のＲＡＴ関連機能性を含んでもよい。] 図５ａ
[0062] 図５ａに示すＬＴＥ実施形態において、ミドルウェア機能２０６は、ＬＴＥ ＯＰＡとして構成される。ミドルウェア機能２０６により実現されるＬＴＥ ＯＰＡは、ＬＴＥプラットフォーム２０４の制御（機能構成要素２１０及び２１２の制御を含むがそれに限定されない）を行なうためにアプリケーション２０８に提供される必要があるＡＰＩ機能を含む。] 図５ａ
[0063] プラットフォーム２０４及びミドルウェア機能２０６は、上述したようにプラットフォームシステム２０２及び１つ以上の更なるプラットフォームシステムのハードウェア及びソフトウェアによる可能な実現化に関する限り参考として本明細書に取り入れられる米国特許第７，１４９，５１０Ｂ２号公報（この特許の図２を参照）から一般に周知であるように単一のＡＳＩＣに組み込まれてもよい。特にそのようなＡＳＩＣは、オープンＯＳ又は自社開発したＯＳ及び必要とされるミドルウェアソフトウェアをサポートする中央処理装置（ＣＰＵ）及びＬＴＥベースバンド制御器を含んでもよい。機能構成要素１１０及び１１２は、ソフトウェアの形態で、ハードウェアの形態で又はソフトウェア／ハードウェアの組合せとしてＡＳＩＣにより実現されてもよい。] 図２
[0064] 図５ａに示す実施形態において、機能構成要素２１０と２１２との間の任意の通信は、プラットフォーム内通信を構成し、例えば従来のプログラミング技術を使用して容易に実現可能である。しかし、この通信状況は、２つの機能構成要素２１０及び２１２が単一のプラットフォームシステムに配置されないデュアルプラットフォームの例において激変する。] 図５ａ
[0065] 図５ｂは、図５ａのプラットフォームシステム２０２が単一のデバイスにおいて類似する更なるプラットフォームシステム２２０と同一の場所に配置されるそのようなデュアルプラットフォームの例を示す。図５ｂに示す更なるプラットフォームシステム２２０は、ＵＭＴＳ規格に従ってＲＡＴをサポートするネットワークアクセスプラットフォーム２２２を含む。] 図５ａ 図５ｂ
[0066] 図５ｂに示すデュアルプラットフォーム実施形態において、プラットフォームシステム２２０のアプリケーション２０８’は、他のプラットフォームシステム２０２に配置される機能構成要素２１０（「モジュールＸ」）にアクセスする必要があってもよい。アプリケーション２０８’は、オープンアプリケーション環境に属してもよい。更にプラットフォームシステム２０２のＬＴＥプラットフォーム２０４により提供される機能構成要素２１０は、プラットフォームシステム２２０のＵＭＴＳプラットフォーム２２２により提供される機能構成要素２１２’（「モジュールＹ」）によりアクセスされる必要があってもよい（又は機能構成要素２１２’にアクセスする必要があってもよい）。そのような類似する通信の例は、効率的なプラットフォーム間通信技術の実現を要求する。] 図５ｂ
[0067] 図１〜図４に関連して上述したように、そのようなプラットフォーム内通信技術は、ミドルウェア機能及びプラットフォーム間通信アプリケーションを含んでもよい。図５ｂに戻ると、第１のミドルウェア機能２０６’を含むミドルウェア層はこのために提供される。ミドルウェア機能２０６’により、プラットフォームシステム２２０のアプリケーション２０８’はプラットフォームシステム２０２に配置される機能構成要素２１０のリモート制御ができる。プラットフォームシステム２２０のミドルウェア機能２０６’は、プラットフォームシステム２０２の対応するミドルウェア機能２０６から導出されている。図５ｂに示すように、プラットフォームシステム２２０は、アプリケーション２０８’がローカル機能構成要素２１２’の制御を含むローカルＵＭＴＳプラットフォーム２２２の機能性の制御を行なえるようにする更なるミドルウェア機能２２３を含む。] 図１ 図２ 図３ 図４ 図５ｂ
[0068] 既に説明したように、プラットフォームシステム２０２の機能構成要素２１０とプラットフォームシステム２２０の機能構成要素２１２’との間の低レベルプラットフォーム間通信が必要とされる場合があるだろう。そのような場合、機能構成要素２１２’と機能構成要素２１０との間にプラットフォーム内通信パスが確立されてもよい。通信パス（図５ｂには示さない）は、プラットフォームシステム２２０により元々提供されているプラットフォーム間通信アプリケーション２２４、並びにミドルウェア層の少なくとも１つのインポートされたミドルウェア機能２１４’又は固有のミドルウェア機能２２６を含む。] 図５ｂ
[0069] ミドルウェア層に関して、図５ｂにおいて２つの例は区別されてもよい。プラットフォームシステム２２０の機能構成要素２１２’がプラットフォームシステム２０２の機能構成要素２１０により提供される機能を呼び出す場合、通信パスは、機能構成要素２１２’からミドルウェア機能２２６、プラットフォーム間通信アプリケーション２２４及びミドルウェア機能２１４’を介して機能構成要素２１０まで達する。一方、機能構成要素２１０が機能構成要素２１２’により提供される機能を呼び出す場合、通信パスは、機能構成要素２１０からミドルウェア機能２１４、プラットフォーム間通信アプリケーション２２４及びミドルウェア機能２２６を介して機能構成要素２１２’まで達する。] 図５ｂ
[0070] 基本的には、ミドルウェア機能２１４’は機能構成要素２１０の機能にアクセスするためのＡＰＩ（ＯＰＡ）を含み、ミドルウェア機能２２６は機能構成要素２１２’の機能にアクセスするためのＡＰＩ（ＯＰＡ）を含む。ミドルウェア機能２１４’は、プログラムコードの形態、図６に関連して以下に説明するようなリモート可視化の形態又は任意の他の形態でプラットフォームシステム２０２からミドルウェア機能２１４をインポートすることにより導出される。] 図６
[0071] 尚、明確にするために、ミドルウェア機能２０６’、２１４’をエクスポート及びインポートするため、並びに通信パスを確立するためのプラットフォーム間インタフェースは、図５ｂには示さない。そのようなインタフェースについては、図８〜図１０に関連して以下に説明する。] 図１０ 図５ｂ 図８ 図９
[0072] 本明細書で説明するプラットフォーム間通信の例において、双方のミドルウェア機能２１４’及び２２６は、同時に通信パスに含まれもよい。ミドルウェア機能２１４’（Ｌ２Ｕ ＯＰＡ）は、プラットフォーム間通信のためのＬＴＥプラットフォームシステム２０２の全ての機能／サービスを含み、ミドルウェア機能２２６（Ｕ２Ｌ ＯＰＡ）は、プラットフォーム間通信のためのＵＭＴＳプラットフォームシステム２２０の全ての機能／サービスを含む。次に、ミドルウェア機能２１４’、２２６の目的について、一方ではＬＴＥプラットフォーム２０４及び他方ではＵＭＴＳプラットフォーム２２２における内部のＲＡＴ（ＩＲＡＴ）測定に関して例示的に説明する。]
[0073] ＬＴＥＩＲＡＴ測定の例から開始すると、ＬＴＥプラットフォーム２０４の機能構成要素２１０がＩＲＡＴ測定を提供でき、一方ではＵＭＴＳプラットフォーム２２２上の機能構成要素２１２’がそのような測定を要求できると仮定する。この例において、ミドルウェア機能２１４’は、機能構成要素２１０からＬＴＥ ＩＲＡＴ測定を要求するサービス（又は要求するためのインタフェース）を機能構成要素２１２’に提供し、ＬＴＥ ＲＡＴにおける測定が実行された後に対応する結果を機能構成要素２１２’に提供する。一方、ミドルウェア機能２２６は、ＵＭＴＳプラットフォーム２２２がＬＴＥ ＲＡＴにおけるＲＡＴ測定をトリガしたいというイベントを購読する可能性（又は購読するためのインタフェース）を機能構成要素２１２’に提供する。更にミドルウェア機能２２６は、対応する測定結果をＵＭＴＳプラットフォーム２２２に転送するサービス（又はインタフェース）を機能構成要素２１２’に提供する。]
[0074] ＵＭＴＳＩＲＡＴ測定の他の例において、ＵＭＴＳプラットフォーム２２２の機能構成要素２１２’がそのような測定を実行でき、その一方でＬＴＥプラットフォーム２０４の機能構成要素２１０がそのような測定を要求できると仮定する。そのような場合、ミドルウェア機能２２６は、ＵＭＴＳ ＲＡＴにおけるＩＲＡＴ測定を要求するサービスを機能構成要素２１０に提供し、ＵＭＴＳ ＲＡＴにおける測定が機能構成要素２１２’により完了された後、対応する結果を機能構成要素２１０に提供する。ミドルウェア機能２１４’は、ＬＴＥプラットフォーム２０４（機能構成要素２１０）がＵＭＴＳ ＲＡＴにおけるＩＲＡＴ測定をトリガしたいというイベントを購読する可能性を機能構成要素２１０に提供する。更にミドルウェア機能２１４は、ＬＴＥプラットフォーム２０４の機能構成要素２１０にＵＭＴＳ ＲＡＴにおける測定結果を転送するサービスを提供する。]
[0075] 上記例から明らかとなるように、ミドルウェア機能２１４’、２２６はある程度補完的である。これは、第１のミドルウェア機能が第１のプラットフォームの機能構成要素に第２のプラットフォームのサービスを提供するが、第２のミドルウェア機能は、第１のプラットフォームが第１のミドルウェア機能により提供されるサービスをトリガしたい場合にイベントを購読する可能性をこの機能構成要素に提供すること、並びにその逆も成り立つことを意味する。]
[0076] 図５ｃは、図５ｂに示す例から導出された別のデュアルプラットフォームの例を示す。図５ｂに示す例とは異なり、プラットフォームシステム２２０の組合せＵＭＴＳプラットフォーム／アプリケーション環境２２２’の内部構造に関する特定の詳細は周知ではない。これは、プラットフォームシステム２２０がデバイスの製造業者の自社開発したシステムプラットフォームでなく、別のメーカから取得された場合に当てはまる。しかし、自社開発したプラットフォームシステム２０２から第三者のプラットフォームシステム２２０にミドルウェア機能２０６、２１４をエクスポート（可視化することを含む）する概念は依然として適用可能であり、機能構成要素２１２”（又は環境２２２’内の任意のアプリケーション）がプラットフォームシステム２０２の機能構成要素２１０にアクセスすることを可能にする。] 図５ｂ 図５ｃ
[0077] ミドルウェア機能のインポートに関して、１つの解決策の本質がプラットフォームシステム２０２からプラットフォームシステム２２０に１つ以上のミドルウェア機能のプログラムコードを転送することにあることは既に説明された。次に、別の可能性について図６を参照して説明する。] 図６
[0078] 図６は、ミドルウェア機能２１４’及び基礎となる機能構成要素に対するアクセス権を図５ｂ及び図５ｃのプラットフォーム間通信アプリケーション２０８’に提供する（すなわち、ミドルウェア機能２１４を「インポートする」）方法を概略的に示す。図６は、中央処理装置（ＣＰＵ）レベルにおけるプラットフォームシステム２０２及び２２０のハードウェア構成を示す。] 図５ｂ 図５ｃ 図６
[0079] 基本的には、分散機能モデル（ＤＦＭ）と呼ばれる機構は、プラットフォームシステム２０２のリモートミドルウェア機能２１４を他方のプラットフォームシステム２２０から見えるようにする（「ローカル」ミドルウェア機能２１４’をシミュレートする）ために使用される。換言すると、プラットフォームシステム２２０のプラットフォーム層の任意の機能構成要素（図６には示さない）がプラットフォーム間通信アプリケーション２０８’及びミドルウェア機能２１４を介するプラットフォームシステム２０２のプラットフォーム層に配置される任意の機能構成要素（図６には示さない）へのアクセス権を提供されるように、ＤＦＭ機構は、ＵＭＴＳプラットフォームシステム２２０及びＬＴＥプラットフォームシステム２０２の２つのＣＰＵを論理的に相互接続するために使用される。この点に関して、ＤＦＭ機構及びミドルウェア機能２１４の組合せは、図５ｂ及び図５ｃに示す「リモート」ミドルウェア機能２１４’を構成するように変換されてもよい。別の観点から、ＤＦＭ機構は、プラットフォームシステム２０２からプラットフォームシステム２２０にミドルウェア機能２１４を「エクスポート」する手段として考えられてもよい。基本的には、ＤＦＭ機構により、プラットフォームシステム２２０のプラットフォーム層の任意の機能構成要素は、対応するミドルウェア機能（ＡＰＩ又はＯＰＡ）２１４が規定されたプラットフォーム２０２のプラットフォーム層に配置される任意の機能構成要素に透過的にアクセス可能になる。] 図５ｂ 図５ｃ 図６
[0080] 図６に示すように、２つのプラットフォームシステム２０２、２２０間に物理リンク２３０が存在する。物理リンク２３０は、プラットフォームシステム２０２の１つ以上の物理インタフェース２３２とプラットフォームシステム２２０の１つ以上の物理インタフェース２３４との間にわたる。物理インタフェース２３２、２３４は、データインタフェース（例えば、ＵＳＢ規格に従う）、制御インタフェース（例えば、ＵＡＲＴ又はＧＰＩＯ規格に従う）又は自社開発したインタフェース（ＰＩＦ）として構成されてもよい。一般にデータインタフェースは、より高性能なハードウェアを要求する代わりに制御インタフェースより速い転送速度をサポートする。例示的なインタフェースの組合せについて、図８〜図１０を参照して以下に説明する。] 図１０ 図６ 図８ 図９
[0081] 更に図６を参照すると、論理プラットフォームＣＰＵ間インタフェース（ＰＰＩＦ）２３６、２３８は、物理インタフェース２３２、２３４の上に配置される。ＰＰＩＦ２３６、２３８は、プラットフォームシステム２０２、２２０の２つのＣＰＵを相互接続するために論理及び物理ハードウェアアクセス層（ＨＡＬ）ドライバと通信する制御ソフトウェアモジュールにより構成される。論理ＰＰＩＦリンク２４０は、ＰＰＩＦモジュール２３６、２３８に基づいて物理リンク２３０上に論理的に確立される。ＰＰＩＦモジュール２３６、２３８の構成を図７に示す。] 図６ 図７
[0082] 図７に示すように、各ＰＰＩＦモジュール２３６、２３８は、物理インタフェースドライバ（ＨＡＬドライバ）を含む最下位層３００を含み、それに続いて論理ドライバ層３０２と、制御副層３０４及びサービス副層３０６を含むＰＰＩＦデータアクセス層を含む。制御副層３０４は、サービス副層３０６におけるサービスの開始及び終了、サービス層における個々のサービス（「リンクタイプ」）に対する入力パケット及び出力パケットのルーティング、並びに関連する多重タスクを処理する。更に制御副層３０４は、サービス副層３０６により提供される個々のサービスのスリープ及び起動論理を管理する。] 図７
[0083] サービス副層３０６は、複数の種々のデータフローをサポートする。この例において、ＤＦＭリンクサービス３０６ａは特に興味深い。基本的には、ＤＦＭリンクサービス３０６ａは、ＰＰＩＦモジュール２３６、２３８の各々と関連するＤＦＭモジュール２４０、２４２との間のＰＤＵ転送を処理する（図６を参照）。ＤＦＭリンクサービス３０６ａは、ミドルウェア機能２１４及びプラットフォーム間通信アプリケーション２０８’に対するＤＦＭリンクを作成及び破壊し且つそれらのＤＦＭリンクにおいてデータを送出及び受信する役割を果たす。] 図６
[0084] サービス副層３０６の仮想外部インタフェース（ＶＥＩ）サービス３０６ｂは、パケット交換（ＰＳ）及び／又は回線交換（ＣＳ）されたデータに対する仮想通信（ＣＯＭ）ポートに対処する。更にＶＥＩサービス３０６ｂは、図６の２つのプラットフォームシステム２０２、２２０の間のＡＴモデムコマンドのやり取りをサポートする。サービス副層３０６により提供される更なるサービスは、ネットワークからの生ＣＳデータを処理し且つビデオアプリケーションに対して生ＣＳデータを転送すること（ビデオサービス３０６ｃ）、リモートシステムプラットフォームに対してデバッグプリントアウトを可視にすること（デバッグサービス３０６ｄ）、インターネットプロトコル（ＩＰ）ユーザデータパケットを転送すること（ＰＳデータサービス３０６ｅ）、並びにＰＰＩＦリンク管理（ＰＰＩＦコマンドの復号化を含む）及び電力管理（制御サービス３０６ｆ）を含む。] 図６
[0085] 図６を参照して、ＤＦＭモジュール２４０、２４２の個々の構成要素について更に詳細に説明する。既に上述したように、ＤＦＭモジュール２４０、２４２は、１つ以上の論理ＤＦＭリンク２４４を確立するためのＰＰＩＦモジュール２３６、２３８に依存する。基本的には、プラットフォームシステム２２０のＤＦＭモジュール２４２（プラットフォーム間通信アプリケーション２０８’の制御下にある）は、任意のＤＦＭリンクを作成する役割を果たす。ＤＦＭリンクが作成されると、２つのプラットフォームシステム２０２、２２０の間のＤＦＭ信号伝送は対称的である。プラットフォーム間通信アプリケーション２０８’と関連付けられるＤＦＭモジュール２４２は、ＤＦＭリンクを閉じる役割を果たす。] 図６
[0086] 各ＤＦＭモジュール２４０、２４２の中央構成要素は、プロキシ及びスタブマネージャ（ＰＳＭ）２４６、２４８である。ＰＳＭ２４６、２４８は、ローカルの機能構成要素のインタフェースを可視化する機能性を実現し、それによりプラットフォームに基づく機能をリモートプラットフォームシステムに提供する。特にＰＳＭ２４６、２４８は、機能構成要素を通信するプロキシ及びスタブを作成する役割を果たす。ミドルウェア機能（ＯＰＡインタフェース）２１４毎に１つのプロキシ／スタブ対（又は「リンク」）が存在し、全てのプロキシ／スタブ対はＰＳＭ２４６、２４８に登録される。プロキシ及びスタブの処理は、ＰＳＭ２４６、２４８内で対称的である。ＰＳＭ２４６、２４８は、ＯＰＡインタフェース毎にプロキシ／スタブリンクを作成し、また、ＯＰＡインタフェースの作成及び削除インスタンスの役割を果たす（構成要素マネージャ２５０、２５２により権限を与えられた時）。]
[0087] プロキシ２５４は、ローカルの構成要素（プラットフォーム間通信アプリケーション２０８’等）からインタフェース要求を受信し且つ関連するリモートスタブ２５６にインタフェース要求をリダイレクトする構成要素である。スタブ２５６は、特定の機能構成要素を参照するインタフェースポインタを有するため、対応するＯＰＡインタフェース（ミドルウェア機能）２１４を介して機能構成要素により提供される機能を使用してもよい。機能構成要素（又は関連するプラットフォーム間通信アプリケーション２０８’）は、リモートの機能構成要素の機能（例えば、メソッド）を呼び出している場合、実際にはプロキシ２５４を呼び出しており、プロキシ２５４は関連するスタブ２６５を呼び出し、スタブ２５６は最終的にリモートの機能構成要素の機能を呼び出す（ミドルウェア機能２１４を介する）。ＤＦＭ機構を使用することにより、プラットフォーム間処理全体は機能構成要素から見て透過的に実行される。]
[0088] ＤＦＭ機構の基礎となる更なる原理は、いわゆるマーシャリング原理である。マーシャリングは、呼び出す機能構成要素の識別子（又は関連するプラットフォーム間通信アプリケーション２０８’の識別子）、呼び出される機能（又は呼び出される機能構成要素）の識別子、並びに呼び出される機能の全てのバッファへの入力パラメータをパックする処理を指定する。この処理は、一般に、プロキシ２５４又はプラットフォーム間通信アプリケーション２０８’により実行される。バッファはＰＳＭ２４８に渡され、ＰＳＭ２４８は自社開発したプロトコル規格又はオープンプロトコル規格に従ってそのバッファをＰＤＵに入れる。ＰＤＵは、ＤＦＭリンク２４４を介してリモートＰＳＭ２４６に送出される。リモートＰＳＭ２４６は、ＰＤＵをアンパックして、そのように回復されたバッファをスタブ２５６に送出する。スタブ２５６において、バッファはアンマーシャリングされ、関連する機能が呼び出される。マーシャリング及びアンマーシャリングは、利用可能になると呼び出される機能の出力パラメータ（戻り値）と同様に実行される。この点に関して、コールバックプロキシ２５８は、プロキシ２５４及びスタブ２５６に関して上述した方法と同様の方法でコールバックスタブ２６０を自動的にトリガする。]
[0089] 図６に示すように、各ＤＦＭモジュール２４０、２４２は、構成要素マネージャ（ＣＭ）２５０、２５２を含む。ＣＭ２５０、２５２は、全ての機能構成要素を管理する役割を果たす。このために、各ＣＭ２５０、２５２は、インスタンスが生成されたプラットフォームシステム２０２、２２０の全てのローカル及びリモートの機能構成要素のリストを保持する。外部又はリモートの構成要素の場合、ＣＭ２５０、２５２はデバイス（例えば、プラットフォームシステム）のデバイス識別子を返し、リモートの構成要素は、ＰＳＭ２４６、２４８が対応する構成要素自体を作成してもよいようにローカルＰＳＭ２４６、２４８に対して配置される。] 図６
[0090] プラットフォームシステム２０２のＤＦＭモジュール２４０は、プロセスマネージャ２６２を更に含む。プロセスマネージャ２６２は、プラットフォームシステム２２０（すなわち、リモートＣＰＵ）からの入力要求を処理するプロセスを生成及び解放する。プロセスの生成及び解放により、ＤＳＭモジュール２４６を妨害することを回避する。]
[0091] 図６のＤＦＭ機構は、ミドルウェア機能により提供されるインタフェースの双方向可視化のための２つ以上のプラットフォームシステムに対称的にインストールされてもよい。そのような例において、一方側の全ての機能構成要素は、単一のプラットフォームチップに配置されているかのように、他方側の機能構成要素にアクセスできる。] 図６
[0092] 図８は、図６における２つのプラットフォームシステム２０２及び２２０の間の物理リンク２３０が確立される際に介する個々の物理インタフェースを示す概略図である。図５ｂ、図５ｃ及び図６の例において既に上述したプラットフォームシステム２０２、２２０の構成要素の説明は省略する。] 図５ｂ 図５ｃ 図６ 図８
[0093] 図８に示すように、２つのプラットフォームシステム２０２、２２０は、一方ではＵＳＢインタフェース２３２ａ、２３４ａにより、並びに他方ではＵＡＲＴインタフェース２３２ｂ、２３４ｂにより並列にリンクされる。ＵＳＢインタフェース２３２ａ、２３４ａは、ＵＳＢイーサネット（登録商標）規格に基づく高速ユーザデータインタフェースを構成する。ＵＳＢインタフェース２３２ａ、２３４ａを介して確立されるＵＳＢリンク（実線の矢印により示されるデータ接続２７０の一部）は、ＵＭＴＳプラットフォーム２２２に常駐するアプリケーションに対するＬＴＥ規格に従うネットワークアクセスを提供する。そのようなアプリケーションは、ＵＭＴＳプラットフォーム上にインストールされるアプリケーション２０８’であってもよく又はプラットフォーム内アプリケーション２０８”であってもよい。データ接続２７０は、ＬＴＥプラットフォーム２０４側でＬＴＥネットワーク信号伝送（ＮＳ）モジュール２７２、イーサネット（登録商標）フレーミングモジュール２７４及びＵＳＢインタフェース２３２ａにわたる。ＵＭＴＳプラットフォーム２２２側では、データ接続２７０は、ＵＳＢインタフェース２３４ａ、イーサネット（登録商標）フレーミングモジュール２７６及びＴＣＰ／ＩＰモジュール２７８にわたる。] 図８
[0094] 点線の矢印により示される制御接続２８０は、２つのＵＡＲＴインタフェース２３２ｂ、２３４ｂにわたる。この制御接続２８０の第１の分岐は、ＬＴＥプラットフォーム２０４の機能構成要素２１０とＵＭＴＳプラットフォーム２２２の機能構成要素２１２’との間にわたる。制御接続２８０のこの分岐を利用する例示的な信号伝送の例について、図１１〜図１４を参照して後述する。] 図１１ 図１２ 図１３ 図１４
[0095] 制御接続２８０の第２の分岐は、ＵＭＴＳプラットフォーム２２２のアプリケーション２０８’からＬＴＥプラットフォーム２０４のミドルウェア機能（ＵＭＴＳプラットフォーム２２２上に示されるインポートされたミドルウェア機能２０６’に対応する）まで及ぶ。ミドルウェア機能２０６及び２０６’は、ＬＴＥプラットフォーム２０４の機能構成要素２１０又は任意の他の機能構成要素にアクセスできるように規定されている。ミドルウェア機能２１４と２０６との間の主な相違点は、ミドルウェア機能２０６（ＬＴＥ ＯＰＡ）がＬＴＥプラットフォーム２０４を制御するためにアプリケーションに提供されるサービス、例えば無線ＯＮ／ＯＦＦ、ネットワーク選択等の設定を含むことに関連する。ミドルウェア機能２１４（Ｌ２Ｕ ＯＰＡ）は、システム制御、ＳＩＭアクセス、ＩＲＡＴハンドオーバ機能及びオプションとしてＡＴコマンドのやり取りのようなＬＴＥプラットフォームのプラットフォーム間通信に対する追加のサービスを含む。]
[0096] ＵＢＳインタフェース２３２ａ、２３４ａがデータ接続２７０上で高速データ転送速度をサポートするが、その一方ではるかに遅いデータ転送速度が制御接続２８０において一般に発生し、このために、複雑さの低いＵＡＲＴインタフェース２３２ｂ、２３４ｂが制御接続２８０におけるプラットフォーム間制御信号伝送のために利用される。]
[0097] 図９に示すインタフェースの例において、図８の２つのＵＡＲＴインタフェース２３２ｂ、２３４ｂは省略されている。この例において、制御接続及びデータ接続の双方は２つのＵＳＢインタフェース２３２ａ、２３４ａにわたる。] 図８ 図９
[0098] 図１０に示すインタフェースの更なる例において、ＵＡＲＴインタフェース２３２ｂ、２３４ｂが低速ユーザデータを転送するために更に使用されるが、高速ユーザデータはＵＳＢインタフェース２３２ａ、２３４ａを介して転送される。] 図１０
[0099] 図８及び図１０に示すインタフェースの例において、ＩＰデータ（ユーザ及びアプリケーションデータを含む）の転送は、制御信号伝送とは別個に処理される。ＩＰデータの場合、ＵＳＢイーサネット（登録商標）機構はＬＴＥプラットフォーム２０４とＵＭＴＳプラットフォーム２２２との間の転送手段として直接使用される。この方法は、特に、プラットフォーム２０４、２２２の一方又は双方が例えばＰＣ又はラップトップに結合されるネットワークカードに常駐する場合に、２つのプラットフォーム２０４、２２２間のＩＰデータの転送機構がプラットフォーム２０４、２２２の一方とパーソナルコンピュータ（ＰＣ）又はラップトップ等の外部デバイスとの間でも使用されてもよい機構であるという利点を有する。] 図１０ 図８
[0100] 尚、ＵＳＢイーサネット（登録商標）サービスを介するＩＰデータ転送のセットアップ、解放等に関するプラットフォーム間制御信号伝送は、当然、ＵＡＲＴを用いた制御信号伝送を介して制御されてもよい。制御信号伝送は、プラットフォームレベルで機能構成要素間の通信を可能にするために、リモートプラットフォームにおけるミドルウェア層の機能を可視化し且つその機能にアクセスするために使用されてもよい。図１０に示すように、制御インタフェース２３２ｂ、２３４ｂは、必要に応じて低速ＩＰデータを転送するためにオプションとして使用されてもよい。] 図１０
[0101] 図８〜図１０に示すＰＰＩＦ機能性に関して、物理インタフェースは、通信チャネルが種々の接続の種類（例えば、ＵＢＳ又はＵＡＲＴのような種々の物理インタフェース）を透過的に使用してもよいようにＰＰＩＦドライバ層に適応されてもよい。物理インタフェースへの通信サービスのマッピングは、自由に構成可能であってもよい。図９に示すように、ＵＳＢ及びＵＡＲＴインタフェース２３２ａ、２３４ａ、２３２ｂ、２３４ｂへの通信サービスの可能なマッピングは、高速ＩＰデータがＵＳＢインタフェース２３２ａ、２３４ａを介して転送される一方で、低速ＩＰデータ及び制御信号がＵＡＲＴインタフェース２３２ｂ、２３４ｂを介して転送されるように選択される。] 図１０ 図８ 図９
[0102] 次に、いくつかの例示的なプラットフォーム間信号伝送の例について図１１〜図１４を参照して説明する。各例において、ＬＴＥプラットフォーム２０４に配置される第１の機能構成要素２１０がＵＭＴＳプラットフォーム２２２に配置される機能構成要素２１２’にアクセスするか又は機能構成要素２１２’を呼び出す（あるいは、機能構成要素２１２’によりアクセスされるか又は呼び出される）と仮定される。これらの信号伝送の実施形態において、ＬＴＥプラットフォーム２０４上に実現される仮想機能構成要素（「仮想モジュールＹ」）２１２’’’が導入される。基本的には、仮想機能構成要素２１２’’’は、機能構成要素２１０に対してＬＴＥプラットフォーム２０４上の機能構成要素２１２’の存在をシミュレートする。この例において、仮想機能構成要素２１２’は、基本的に変換タスクを実行し、機能構成要素２１０の前のプロキシとしての役割を果たす。必要に応じて、同様の仮想機能構成要素（不図示の「仮想モジュールＸ」）は、機能構成要素２１２’の前のプロキシとしてＵＭＴＳプラットフォーム２２２にインストールされてもよい。] 図１１ 図１２ 図１３ 図１４
[0103] 以下の信号伝送の各実施形態において、ＵＭＴＳプラットフォーム２２２側のミドルウェア機能２１４’は、図６と関連して上述したＤＦＭ機構を使用してＵＭＴＳプラットフォーム２２２からインポートされていると仮定される。これは、機能構成要素２１４’がＵＭＴＳプラットフォーム２２２側に実質的に存在しているが、機能構成要素２１４’の基礎となる実際のプログラムコードがＬＴＥプラットフォーム２０４側に機能構成要素２１４の形態で常駐することを意味する。当然、図１１〜図１４には示さない別の例において、対応するプログラムコードは、ＵＭＴＳプラットフォーム２２２側に元々既にインストールされていてもよく、あるいはデバイスの製造中又は製造後にＬＴＥプラットフォーム２０４からＵＭＴＳプラットフォーム２２２に物理的に転送されてもよい。] 図１１ 図１２ 図１３ 図１４ 図６
[0104] 図１１を参照して、ＬＴＥプラットフォーム２０４上のネットワーク信号伝送（ＮＳ）モジュール２１０’の形態の機能構成要素によりＵＭＴＳプラットフォーム２２２上のＳＩＭモジュール２１２’の形態の機能構成要素からの暗号化パラメータの要求を含む信号伝送の例について説明する。] 図１１
[0105] この第１の信号伝送の例の前提条件として、プラットフォーム間通信アプリケーション２２４は、信号伝送ステップ（１）及び（２）により示されるように、ミドルウェア機能２１４’を介する仮想機能構成要素２１２’’’の関連する信号伝送イベントを購読する。プラットフォーム間通信アプリケーション２２４から仮想機能構成要素２１２’’’に送出される対応する購読メッセージは、ＮＳモジュール２１０が任意の暗号化パラメータを要求するかをプラットフォーム間通信アプリケーション２２４が通知されたことを仮想構成要素２１２’’’に通知する。]
[0106] 信号伝送ステップ（３）は、ＮＳモジュール２１０から仮想機能構成要素２１２’’’にそのような暗号化パラメータの要求を送信する（リモートＳＩＭモジュール２１２’がＬＴＥプラットフォーム２０４上のＮＳモジュールと同一の場所に配置されることをＬＴＥプラットフォーム２０４上のＮＳモジュールが仮定するため）ことを示す。プラットフォーム間通信アプリケーション２２４は、ＮＳモジュール２１０からのそのような信号伝送イベントを既に購読しており、仮想機能構成要素２１２’’’は、ＮＳモジュール２１０から受信した要求を事前定義済みの信号伝送イベントに変換する。この変換ステップは、信号伝送ステップ（３）で受信された要求をプラットフォーム間通信アプリケーション２２４により読み出し可能な形式を有するイベントメッセージにパックすることを含んでもよい。信号伝送ステップ（４）及び（５）において、変換された要求を含むイベントメッセージは、仮想機能構成要素２１２’’’からミドルウェア機能２１４’を介してプラットフォーム間通信アプリケーション２２４に転送される。]
[0107] プラットフォーム間通信アプリケーション２２４は、仮想機能構成要素２１２’’’からイベントメッセージを受信した後、イベントメッセージをＳＩＭモジュール２１２’により読み出し可能な要求に再度変換する。対応する暗号化パラメータの要求は、信号伝送ステップ（６）及び（７）により示されるように更なるミドルウェア機能２２６を介してＵＭＴＳプラットフォーム２２２に常駐するＳＩＭモジュール２１２’に転送される。]
[0108] 次のステップにおいて、ＳＩＭモジュール２１２’は、受信した要求を実行し、要求された暗号化パラメータと共に応答メッセージをミドルウェア機能２２６を介してプラットフォーム間通信アプリケーション２２４に送出する。これを信号伝送ステップ（８）及び（９）により示す。]
[0109] プラットフォーム間通信アプリケーション２２４は、受信した応答メッセージを仮想機能構成要素２１２’’’により変換可能な要求メッセージに変換する。要求メッセージは、信号伝送ステップ（１０）及び（１１）において、ミドルウェア機能２１４’を介して仮想機能構成要素２１２’’’に転送される。この点に関して、ミドルウェア機能２１４’は、仮想機能構成要素２１２’’’に対してＡＰＩとして動作する。]
[0110] 仮想機能構成要素２１２’’’は、プラットフォーム間通信アプリケーション２２４から受信した要求メッセージをＮＳモジュール２１０により予想される形式に再度変換する。要求された暗号化パラメータを含む対応する応答メッセージは、最終的に信号伝送ステップ（１２）においてＮＳモジュール２１０に送出される。]
[0111] ＵＭＴＳプラットフォーム２２２に配置される機能構成要素２１２’からＬＴＥプラットフォーム２０４に配置される別の機能構成要素２１０への信号伝送イベントの送信に関連する更なる信号伝送実施形態について、図１２を参照して説明する。対応するプラットフォームレベルのイベントは、ＵＭＴＳプラットフォーム２２２上のＳＩＭモジュール２１２’の形態の機能構成要素により検出されるＳＩＭ状態の変化であってもよい。ＳＩＭ状態のこの変化は、ＬＴＥプラットフォーム２０４の機能構成要素２１０に信号伝送される必要がある。機能構成要素２１０及び／又はプラットフォーム間通信アプリケーション２２４は、図１１の信号伝送の例と関連して説明されたようにそのようなイベントをオプションとして既に購読していてもよい。] 図１１ 図１２
[0112] ＳＩＭモジュール２１２’は、ＳＩＭ状態の変化を検出すると、対応するイベントメッセージを生成し、信号伝送ステップ（１）及び（２）により示すようにミドルウェア機能２２６を介してプラットフォーム間通信アプリケーション２２４にそのメッセージを転送する。]
[0113] プラットフォーム間通信アプリケーション２２４は、受信したイベントメッセージをＬＴＥプラットフォーム２０４の仮想機能構成要素２１２’’’により読み出し可能な要求メッセージに変換する。対応する要求メッセージは、信号伝送ステップ（３）及び（４）において、ミドルウェア機能２１４’を介して仮想機能構成要素２１２’’’に転送される。]
[0114] 仮想機能構成要素２１２’’’は、要求メッセージをイベントメッセージ（すなわち、機能構成要素２１０により読み出し可能な形式）に再度変換し、信号伝送ステップ（５）において、結果として得られるイベントメッセージを機能構成要素２１０に送出する。]
[0115] 次に、ＵＭＴＳプラットフォーム２２２内に配置される機能構成要素２１２’（本明細書においてはＩＰモジュール）からＬＴＥプラットフォーム２０４内に配置される機能構成要素２１０に送出された要求メッセージに関する別の信号伝送の例について、図１３を参照して説明する。そのような要求メッセージは、例えばＵＭＴＳプラットフォーム２２２上のＩＰモジュール２１２’の形態の機能構成要素からＬＴＥプラットフォーム２０４上のＮＳモジュール２１０の形態の機能構成要素に送出されたパケットデータプロトコル（ＰＤＰ）コンテキストアクティブ／非アクティブ要求であってもよい。] 図１３
[0116] 前提条件として、プラットフォーム間通信アプリケーション２２４は、ＩＰモジュール２１２’及び仮想機能構成要素２１２’’’の信号伝送イベントを購読する。対応する購読メッセージは、信号伝送ステップ（１ａ）及び（２ａ）、並びに信号伝送ステップ（１ｂ）及び（２ｂ）においてそれぞれ転送される。]
[0117] イベントに基づく処理は、ＩＰモジュール２１２’がＰＤＰコンテキストアクティブ／非アクティブイベントを検出し且つプラットフォーム間通信アプリケーション２２４にこのイベントを通知した時に開始する。対応する通知は、信号伝送ステップ（３）及び（４）により示されるようにミドルウェア機能２２６を介して転送される。イベントは、双方のモジュール２１０、２１２’が１つの同一のプラットフォーム上の同一の場所に配置されるスタンドアロンプラットフォーム構成においてＮＳモジュール２１０に直接転送される対応する要求を置換する。]
[0118] プラットフォーム間通信アプリケーションは、イベントを仮想機能構成要素２１２’’’により変換可能な要求に再度変換する。結果として得られる要求メッセージは、信号伝送ステップ（５）及び（６）においてミドルウェア機能２１４’を介して仮想機能構成要素２１２’’’に転送される。]
[0119] 仮想機能構成要素２１２’’’は、受信した要求メッセージをＮＳモジュール２１０に転送する。この場合、仮想機能構成要素２１２’’’は、（必ずしも）変換タスクを実行する必要はない。ＮＳモジュール２１０は、仮想機能構成要素２１２’’’から要求メッセージを受信すると、応答メッセージを生成し、信号伝送ステップ（８）においてこの応答メッセージを仮想機能構成要素２１２’’’に送信する。仮想機能構成要素２１２”は、受信した応答メッセージをプラットフォーム間通信アプリケーション２２４により変換可能なイベントメッセージを変換し、信号伝送ステップ（９）及び（１０）により示されるように、ミドルウェア機能２１４’を介してプラットフォーム間通信アプリケーション２２４にイベントメッセージを送出する。]
[0120] プラットフォーム間通信アプリケーション２２４は、仮想機能構成要素２１２’’’から受信したイベントメッセージをＩＰモジュール２１２’により読み出し可能な要求メッセージに再度変換し、ミドルウェア機能２２６を介してＩＰモジュール２１２’にそのように生成された要求メッセージを転送する。対応する信号伝送ステップ（１１）及び（１２）を図１３に示す。ＩＰモジュール２１２’により要求メッセージを受信すると、ＮＳモジュール２１０がＵＭＴＳプラットフォーム２２２上のＩＰモジュールと同一の場所に配置される場合にＮＳモジュール２１０から直接取得された対応する応答メッセージが置換される。] 図１３
[0121] 次に、信号伝送の最後の例について図１４を参照して説明する。この信号伝送の例は、ＬＴＥプラットフォーム２０４上に配置される機能構成要素２１０からＵＭＴＳプラットフォーム２２２上に配置されるリモート機能構成要素２１２’にイベントメッセージを送信することに関する。そのようなイベントメッセージは、ＰＤＰコンテキスト状態変化を示してもよく、一般にこれは、ＬＴＥプラットフォーム２０４上のＮＳモジュール２１０の形態の機能構成要素からＵＭＴＳプラットフォーム２２２上のＩＰモジュール２１２’の形態の機能構成要素に信号伝送される。] 図１４
[0122] 図１１を参照すると、信号伝送は、ＮＳモジュール２１０がＰＤＰコンテキスト状態変化を検出することにより開始する。ＮＳモジュール２１０は、そのような状態変化を検出すると、対応するイベントメッセージを生成し、信号伝送ステップ（１）においてイベントメッセージを仮想機能構成要素２１２’’’に送信する。仮想機能構成要素２１２’’’は、受信したイベントメッセージをミドルウェア機能２１４’を介してプラットフォーム間通信アプリケーション２２４に転送する。この処理は、図１１の信号伝送ステップ（２）及び（３）により示される。] 図１１
[0123] プラットフォーム間通信アプリケーション２２４は、イベントメッセージをＩＰモジュール２１２’により変換可能な要求メッセージに変換する。対応する要求メッセージは、信号伝送ステップ（４）及び（５）においてミドルウェア機能２２６を介してＩＰモジュール２１２’に転送される。この要求メッセージは、ＮＳモジュール２１０がＵＭＴＳプラットフォーム２２２上のＩＰモジュール２１２’と同一の場所に配置された場合にＩＰモジュール２１２’により受信される対応するイベントメッセージを置換する。]
[0124] 尚、当然、上述の信号伝送の例は拡張可能であり、他の信号伝送の例も考えられる。例えば、リモートに配置される機能構成要素間でやり取りされるイベントメッセージ及び要求メッセージにおける上述の信号伝送の概念は、図示するＬＴＥ及びＵＭＴＳプラットフォーム等の２つのネットワークアクセスプラットフォーム間の内部のＮＡＴ又はＲＡＴハンドオーバ信号伝送を達成するために実現される。更に、例えばシステム制御、無線制御又はＳＩＭロック制御に関連するプラットフォーム間制御メッセージが実現される。信号伝送は、特にネットワークアクセス関連メッセージに関係してもよいが、これらに限定されない。そのようなメッセージは、２つのネットワークアクセスプラットフォーム間のＡＴコマンド等のモデムコマンドのやり取りを含んでもよい。]
[0125] 一方のネットワークアクセスプラットフォームから他方のネットワークアクセスプラットフォームへの信号伝送は、オプションとして、図６に示すＤＦＭ機構において上述したコールバック機能性によりトリガされてもよい。例えば図６のＬＴＥプラットフォームＣＰＵ２０２上で実現されるＲＡＴからＬ１測定値を取得するイベントの生成をトリガするために、ＵＭＴＳプラットフォームＣＰＵ２２０は、最初に、Ｌ１測定値がＬＴＥプラットフォーム側から要求されることをＬＴＥプラットフォームＣＰＵ２０２に通知する必要がある（対応するミドルウェア機能を介する）。対応するＬ１測定値が最終的に受信された場合、ＬＴＥプラットフォームＣＰＵ２０２は、ＵＭＴＳプラットフォームＣＰＵ２０２に測定結果を転送するために対応するコールバック機能によりＵＭＴＳプラットフォームＣＰＵ２２０をトリガする。この点に関して、図１３及び図１４に示す同様の信号フローが実現可能である。] 図１３ 図１４ 図６
[0126] 上記実施形態において、単一の標準的なプラットフォームシステム（上述のＬＴＥプラットフォームシステム等）は、複数の種々の他のプラットフォームシステムのうちの１つ（いくつかのＵＭＴＳプラットフォームシステムのうちの１つ等）と組み合わされることが考えられるだろう。そのような場合、他のプラットフォームシステムの各々が標準的なプラットフォームシステムにより提供されるミドルウェア機能に特に適応する必要がある場合があり、そのような場合、アプリケーション又はミドルウェア層に提供されるプラグインモジュールは、必要な適応を実現するために使用されてもよい。適切なプラグインは、例えば図６に示すＤＦＭ機構を使用して「リモート」ミドルウェア機能に転送されてもよい。] 図６
[0127] ミドルウェア機能に関してエクスポート機能性を有する標準的なプラットフォームシステムと組み合わされるプラットフォームシステムがＵＳＢ又はＵＡＲＴ等のオープンインタフェース規格のいずれもサポートしない場合、そのようなオープンインタフェースは、２つのプラットフォームシステム間に配置される共有ランダムアクセスメモリ（ＲＡＭ）にアクセスする自社開発したインタフェースにより置換される。]
[0128] 好適な実施形態の上記説明から明らかであるように、本明細書で提案されるプラットフォーム間通信機構は、共有機能構成要素との別個のプラットフォームシステムの接続を容易にする。この方法により、例えばＳＩＭアクセス、プラットフォーム間ＮＡＴハンドオーバ機構及びシステム制御等に関連するプラットフォーム間機能の提供が可能になる。]
[0129] 単一のシステムプラットフォームは、スタンドアロン構成（デバイスの単一のプラットフォームシステムである）又はデュアルモード構成（デバイスの１つ以上の更なるプラットフォームシステムを含む）のいずれかに選択的にインストールされるように構成されてもよい。特に、非常に類似するインタフェース機構は１つのネットワークアクセスプラットフォームのそのような種々の展開に対して使用されてもよい。]
[0130] ＵＳＢ及びＵＡＲＴ等の標準化され且つ一般に使用されるインタフェース規格を使用して一方のネットワークアクセスプラットフォームを他方のネットワークアクセスプラットフォームに接続することにより、種々の製造業者のアプリケーションプラットフォーム及びネットワークアクセスプラットフォームシステムに対する特定のネットワークアクセスプラットフォームシステムの適応が容易になる。第三者プラットフォームシステムに対する特定のネットワークアクセスプラットフォームシステムの適応は、プラットフォーム間通信インタフェース及びプロトコルをカプセル化することにより更に容易になる。また、任意の発呼側機能構成要素が必ずしも１つの同一のネットワークアクセスプラットフォームシステム又は１つの同一のデバイス上の着呼側機能構成要素と同一の場所に配置される必要がないため、個々のネットワークアクセスプラットフォームシステムのリモート制御が可能である。この方法により、ローカルで利用不可能である特定の機能が実現される必要がある場合に他のプラットフォームシステムに接続する「効率的な」プラットフォームシステムの導入が可能になる。]
[0131] 本発明の利点は、上述の説明から完全に理解されると考えられ、種々の変更は、本発明の範囲から逸脱せずに又は全ての利点を犠牲にすることなく本発明の例示的な態様の形態、構成及び配置において行なわれてもよいことが明らかとなるだろう。本発明は、多くの方法で変更可能であるため、以下の請求の範囲の範囲によってのみ限定されるべきであることが理解されるだろう。]

权利要求:

請求項1
種々のネットワークアクセスプラットフォーム（１０６、１１２；２０４、２２２、２２２’）に配置される機能構成要素（１２０、１３０；２１０、２１２’）間の通信を確立する方法であって、前記方法は、第２のネットワークアクセスプラットフォーム（１０６；２０４）に配置される第２の機能構成要素（１３０；２１０）にプラットフォームに基づく機能を提供することと、前記第２の機能構成要素（１３０；２１０）からプラットフォームに基づく機能を要求することとの少なくとも一方を行うように構成される第１の機能構成要素（１２０；２１２’；２１２’’）を含む第１のネットワークアクセスプラットフォーム（１１２；２２２；２２２’）を提供する工程と、前記第１の機能構成要素（１２０；２１２’；２１２’’）と前記第２の機能構成要素（１３０；２１０）との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーション（１２２；２２４）を前記第１のネットワークアクセスプラットフォーム（１１２；２２２；２２２’）にインストールする工程と、前記プラットフォーム間通信アプリケーション（１２２；２２４）が前記第２の機能構成要素（１３０；２１０）にアクセスするために提供される第１のミドルウェア機能（１２６；２１４’）と接続することを可能にする工程と、前記プラットフォーム間通信アプリケーション（１２２；２２４）及び前記第１のミドルウェア機能（１２６；２１４’）を介して前記第１の機能構成要素（１２０；２１２’；２１２’’）と前記第２の機能構成要素（１３０；２１０）との間に通信パス（１３４；２８０）を確立する工程と、を備えることを特徴とする方法。
請求項2
前記第１のミドルウェア機能は、前記第２のネットワークアクセスプラットフォームを介してアクセス可能であり、前記プラットフォーム間通信アプリケーションが前記第１のミドルウェア機能と接続することを可能にする工程は、前記第１のネットワークアクセスプラットフォームに第１のインタフェース（１２４）を提供する工程と、前記第１のインタフェース（１２４）を前記第２のネットワークアクセスプラットフォームの第２のインタフェース（１２８）に結合する工程と、を備えることを特徴とする請求項１に記載の方法。
請求項3
前記第１のインタフェース及び前記第２のインタフェースは各インタフェースを制御するように構成され、前記第１のネットワークアクセスプラットフォームに第１のデータインタフェースを提供する工程と、前記第１のデータインタフェースをデータ交換のために前記第２のネットワークアクセスプラットフォームの第２のデータインタフェースに結合する工程と、をさらに備えることを特徴とする請求項２に記載の方法。
請求項4
前記第２のネットワークアクセスプラットフォームから前記第１のミドルウェア機能をインポートする工程をさらに備えることを特徴とする請求項１乃至３の何れか１項に記載の方法。
請求項5
前記第１のネットワークアクセスプラットフォームと前記第２のネットワークアクセスプラットフォームとの間で転送された信号をカプセル化および非カプセル化するように構成されるカプセル化機構（２４０；２４２）を前記通信パスに挿入する工程をさらに備えることを特徴とする請求項１乃至４の何れか１項に記載の方法。
請求項6
前記カプセル化機構は、前記プラットフォーム間通信アプリケーションと前記第１のミドルウェア機能との間で前記通信パスに論理的に挿入されることを特徴とする請求項５に記載の方法。
請求項7
前記第２のネットワークアクセスプラットフォームに配置される仮想機能構成要素（２１２’’’）を前記通信パスに挿入する工程をさらに備え、前記仮想機能構成要素は、前記第２のネットワークアクセスプラットフォーム上に前記第１の機能構成要素が存在することを前記第２の機能構成要素に対してシミュレートすることを特徴とする請求項１乃至６の何れか１項に記載の方法。
請求項8
前記仮想機能構成要素は、前記通信パスにおいて起こる信号伝送に関してプラットフォーム変換タスクを実行することを特徴とする請求項７に記載の方法。
請求項9
前記プラットフォーム間通信アプリケーションによって、前記第１の機能構成要素、前記第２の機能構成要素、及び前記仮想機能構成要素の少なくとも１つの信号伝送イベントを購読する工程をさらに備えることを特徴とする請求項７または８に記載の方法。
請求項10
前記プラットフォーム間通信アプリケーションは、前記通信パスにおいて起こる信号伝送に対して変換タスクを実行することを特徴とする請求項１乃至９の何れか１項に記載の方法。
請求項11
前記確立された通信パスを介して、前記第１のネットワークアクセスプラットフォームと前記第２のネットワークアクセスプラットフォームとの間のハンドオーバ信号、購読者識別モジュール（ＳＩＭ）カードを含むスマートカード又はメモリカードへのアクセスを含む信号、システム制御信号、及びモデムコマンド信号の少なくとも１つを転送する工程をさらに備えることを特徴とする請求項１乃至１０の何れか１項に記載の方法。
請求項12
前記第１の機能構成要素へのアクセス権を提供するように構成される第２のミドルウェア機能（２２６）を提供する工程をさらに備えることを特徴とする請求項１乃至１１の何れか１項に記載の方法。
請求項13
前記第２のミドルウェア機能は、前記プラットフォーム間通信アプリケーションと前記第１の機能構成要素との間で前記通信パスにおいて論理的に構成されることを特徴とする請求項１２に記載の方法。
請求項14
前記第２のミドルウェア機能は、前記第１のネットワークアクセスプラットフォームに物理的に常駐することを特徴とする請求項１２または１３に記載の方法。
請求項15
前記第１のミドルウェア機能と前記第２のミドルウェア機能のうち少なくとも１つは、アプリケーションプログラミングインタフェース（ＡＰＩ）を備えることを特徴とする請求項１乃至１４の何れか１項に記載の方法。
請求項16
前記第１の機能構成要素、前記第２の機能構成要素、または第３の機能構成要素（２０６’；２２３）のうち少なくとも１つは、オープンアプリケーション環境のローカルアプリケーションにさらにアクセス可能であることを特徴とする請求項１乃至１５の何れか１項に記載の方法。
請求項17
前記第１のネットワークアクセスプラットフォームは、少なくとも１つの第１の無線アクセス技術（ＲＡＴ）をサポートする第１のベースバンドコントローラを備え、前記第２のネットワークアクセスプラットフォームは、前記少なくとも１つの第１のＲＡＴとは異なる第２のＲＡＴをサポートする第２のベースバンドコントローラを備えることを特徴とする請求項１乃至１６の何れか１項に記載の方法。
請求項18
前記第１のネットワークアクセスプラットフォーム及び前記第２のネットワークアクセスプラットフォームは単一のデバイス（１００）内で同一の場所に配置されることを特徴とする請求項１乃至１７の何れか１項に記載の方法。
請求項19
種々のネットワークアクセスプラットフォーム（２０４、２２２）に配置される機能構成要素間の通信を確立する方法であって、前記方法は、第２のネットワークアクセスプラットフォーム（２２２）に配置される第２の機能構成要素（２１２’）にプラットフォームに基づく機能を提供することと、前記第２の機能構成要素（２１２’）から前記プラットフォームに基づく機能を要求することとの少なくとも一方を行うように構成される第１の機能構成要素（２１０）を含む第１のネットワークアクセスプラットフォーム（２０４）を提供する工程と、前記第１の機能構成要素（２１２’）へのアクセスを可能にするミドルウェア機能（２１４）を前記第１のネットワークアクセスプラットフォーム（２０４）にインストールする工程と、ミドルウェア機能（２１４）及びプラットフォーム間通信アプリケーション（２２４）を介して前記第１の機能構成要素と前記第２の機能構成要素との間に通信パス（２８０）を確立する工程と、を備えることを特徴とする方法。
請求項20
コンピュータプログラムが１つ以上のコンピュータデバイス上で動作する場合に、請求項１乃至１９の何れか１項に記載の前記工程を実行させるためのコンピュータプログラム。
請求項21
コンピュータ読み取り可能な記録媒体に格納されることを特徴とする請求項２０に記載のコンピュータプログラム。
請求項22
種々のネットワークアクセスプラットフォーム（２０４、２２２）に配置される機能構成要素（２１０、２１２’）間の通信を可能にするように構成されるプラットフォームシステム（２２０）であって、前記システムは、第２のネットワークアクセスプラットフォーム（２０４）に配置される第２の機能構成要素（２１０）にプラットフォームに基づく機能を提供することと、前記第２の機能構成要素（２１０）からプラットフォームに基づく機能を要求することとの少なくとも一方を行うように構成される第１の機能構成要素（２１２’）を含む第１のネットワークアクセスプラットフォーム（２２２）と、前記第１のネットワークアクセスプラットフォーム（２２２）にインストールされ且つ前記第１の機能構成要素（２１２’）と前記第２の機能構成要素（２１０）との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーションと、前記プラットフォーム間通信アプリケーション（２２４）が前記第２の機能構成要素（２１０）にアクセスするために提供されるミドルウェア機能（２１４’）と接続することを可能にするように構成されるインタフェース（２３４ａ、２３４ｂ）と、前記プラットフォーム間通信アプリケーション（２２４）及び前記ミドルウェア機能（２１４’）を介して前記第１の機能構成要素（２１２’）と前記第２の機能構成要素（２１２’）との間に通信パス（２８０）を確立するように構成される制御器（１３２）と、を備えることを特徴とするプラットフォームシステム。
請求項23
前記プラットフォームシステムは、ユニバーサル移動通信システム（ＵＭＴＳ）規格に従って構成されることを特徴とする請求項２２に記載のプラットフォームシステム。
請求項24
前記インタフェースは、ＵＳＢ又は汎用非同期送受信機（ＵＡＲＴ）インタフェースの少なくとも１つとして構成されることを特徴とする請求項２２または２３に記載のプラットフォームシステム。
請求項25
種々のネットワークアクセスプラットフォーム（２０４、２２２）に配置される機能構成要素（２１０、２１２’）間の通信を可能にするように構成されるプラットフォームシステム（２０２）であって、前記システムは、第２のネットワークアクセスプラットフォーム（２２２）に配置される第２の機能構成要素（２１２’）にプラットフォームに基づく機能を提供することと、前記第２の機能構成要素（２１２’）からプラットフォームに基づく機能を要求することとの少なくとも一方を行うように構成される第１の機能構成要素（２１０）を含む第１のネットワークアクセスプラットフォーム（２０４）と、前記第１のネットワークアクセスプラットフォーム（２０４）にインストールされ且つ前記第１の機能構成要素（２１２’）へのアクセスを可能にするように構成されるミドルウェア機能（２１４）と、前記ミドルウェア機能及びプラットフォーム間通信アプリケーション（２２４）を介して前記第１の機能構成要素（２１０）と前記第２の機能構成要素（２１２’）との間に通信パス（２８０）を確立するように構成される制御器（１３２）、を備えることを特徴とするプラットフォームシステム。
請求項26
前記プラットフォームシステムは、ＬＴＥ（Long Term Evolution）規格に従って構成されることを特徴とする請求項２５に記載のプラットフォームシステム。
請求項27
デュアルプラットフォームデバイスであって、第１の機能構成要素（２１２’）を含む第１のネットワークアクセスプラットフォーム（２２２）と、前記第１のネットワークアクセスプラットフォーム（２２２）に配置される前記第１の機能構成要素（２１２’）にプラットフォームに基づく機能を提供することと、前記第１の機能構成要素（２１２’）からプラットフォームに基づく機能を要求することとの少なくとも一方を行うように構成される第２の機能構成要素（２１０）を含む第２のネットワークアクセスプラットフォーム（２０４）と、前記第１の機能構成要素（２１２’）と前記第２の機能構成要素（２１０）との間の信号伝送を制御するように構成されるプラットフォーム間通信アプリケーションと、前記第１の機能構成要素（２１２’）と前記第２の機能構成要素（２１０）との少なくとも１つへのアクセスを可能にするように構成されるミドルウェア機能（２１４、２２６）と、前記プラットフォーム間通信アプリケーション（２２４）及び前記ミドルウェア機能（２１４’）を介して前記第１の機能構成要素（２１２’）と前記第２の機能構成要素（２１０）との間に通信パス（２８０）を確立するように構成される制御器（１３２）と、を備えることを特徴とするデュアルプラットフォームデバイス。
請求項28
前記デュアルプラットフォームデバイスは、ネットワークカード、携帯端末、及び移動電話のうち少なくとも１つとして構成されることを特徴とする請求項２７に記載のデュアルプラットフォームデバイス。
請求項29
前記機能構成要素は、レイヤ１（Ｌ１）測定、ＳＩＭアクセス、ハンドオーバ信号伝送、システム制御信号、または、モデムコマンド信号伝送のうち少なくとも１つを要求または提供するモジュールとして構成されることを特徴とする請求項２７または２８に記載のデュアルプラットフォームデバイス。